home *** CD-ROM | disk | FTP | other *** search
/ Amiga Format CD 33 / Amiga Format AFCD33 (Issue 117, Dec 1998).iso / -seriously_amiga- / programming / c / qtools0.2 / archives / qtools0.2-deb.lha / TODO < prev   
Text File  |  1998-07-19  |  3KB  |  74 lines
  1.  
  2.  allready done:
  3.  
  4.       possibly use cpp as preprocessor for quakec (do not open the source-file
  5.     directly, instead open a pipe, into that cpp pipes (alternativly use
  6.     tempfile instead))
  7.  
  8.  partially done:
  9.  
  10.       support for quake2 (some things have been done for this)
  11.     
  12.       loading/saving of models
  13.   
  14.       ilbm/gif/pcx/bmp-support (but, I'm not the man to programm that crap
  15.     , some has been done, but not everything)
  16.   
  17.       alias-lists for texture-names: we expand an array of texturenames and its
  18.     aliases "alias\0texturename\0texturepath", so life is easy if you change your
  19.     texturenames on your harddrive or want to replace the standard-textures with
  20.     your own. and it is faster than searching through all your directories all
  21.     the time.
  22.   
  23.  future ideas:
  24.   
  25.       use zlib instead of own compression algorithm?  (already in, but only
  26.     used for png)
  27.   
  28.       make-like timestamp-updating?
  29.   
  30.       lot of dokumentation (the whole source)
  31.   
  32.       support for the extensions of bsp/worldcraft/... like prefabs etc.
  33.   
  34.       if there are '/' in the mipmaps-name, we try to load wals instead of wads
  35.     (minor change, based upon the dir-keyword) [so it is possible to compile
  36.     quakeII-maps for quakeI
  37.   
  38.       redefine some of the unused fields in structs for fast viewers (eg.  a
  39.     fullcolor-field in miptexs, or a group-id in wads)
  40.   
  41.       specify "lightcolors" in map-files for colored lights (quakeI and
  42.     quakeII), the lightmaps for colored light are saved after the normal
  43.     lightmaps, so we get get red-lightmap at "lightdatasize/4", green at
  44.     "lightdatasize/4 * 2", blue at "lightdatasize/4 * 3", that way it is
  45.     completely comatible to quake (dont forget to add lightofs)
  46.   
  47.       a basic idea to enhance the bsp-format:  after the bspheader we have room
  48.     for everything we want.  the standard-header has offsets into the file, so
  49.     quake nor any other program that READ the file, expects that eg.  the
  50.     entity-lump lies after the header.  now we build a crc-sum, or something
  51.     other union like a magic number.  we put that directly after the header.
  52.      now if we look for an enhanced bsp-file we check that number and voila
  53.     we put everything what we want into the bsp-file.
  54.      some ideas for extensions:
  55.      - write the texture-strings into a lump a save them, but don't load the
  56.     textures, so we have the same capability as quakeII for quakeI, but it
  57.     doesn't work for quakeI.exe, 'cause quakeI misses the texture-lump
  58.      - we can save the precalculated values from qview into a special lump
  59.      - we can save the colored light-tables into a special lump instead after
  60.     the original lightmaps
  61.      - ...
  62.   
  63.       an idea to patch a pre-processed pak-file that the bsp-files shares
  64.     textures:  first we create a wad, that contains all the textures that are
  65.     in the bsps (not in one, in all).  than we create the bsps without adding
  66.     the textures and build the pak-file.  now we post-process the bsps directly
  67.     in the pak-file (the bsps offsets to the textures exists but are -1) that
  68.     the offsets point into the location of the texture in the wad-file in the
  69.     pak-file.
  70.     
  71.  ...  (too much)
  72.  
  73.  suggestions are welcome!
  74.